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Abstract 

Trust  management  is  a  form  of  access  control  that  uses 
delegation  to  achieve  scalability  beyond  a  single  organiza¬ 
tion  or  federation.  However,  delegation  can  be  difficult  to 
control.  A  resource  owner  that  delegates  some  authority  is 
naturally  concerned  not  only  about  who  has  access  today, 
but  also  who  will  have  access  after  others  make  changes 
to  the  global  policy  state.  They  need  tools  to  help  answer 
such  questions.  This  problem  has  been  studied  in  the  case 
of  a  trust  management  language  called  RT,  where,  for  sim¬ 
ple  questions  concerning  specific  individuals,  polynomial 
time  algorithms  are  known.  However,  more  useful  ques¬ 
tions,  like  “Could  anyone  who  is  not  an  employee  ever  get 
access  ?”  are  in  general  intractable.  This  paper  concerns 
our  efforts  to  build  practical  tools  that  answer  such  ques¬ 
tions  in  many  cases  nevertheless  by  using  a  lightweight  ap¬ 
proach  that  leverages  a  mature  model  checking  tool  called 
SMV.  Model  checking  is  an  automated  technique  that  checks 
if  desired  properties  hold  in  the  model.  Our  experience,  re¬ 
ported  here,  suggests  that  in  our  problem  domain,  such  a 
tool  may  often  be  able  to  identify  delegations  that  are  unsafe 
with  respect  to  security  questions  like  the  one  mentioned 
above.  We  explain  our  translation  from  a  RT  policy  and 
containment  query  to  an  SMV  model  and  specification  as 
well  as  demonstrate  the  feasibility  of  our  approach  with  a 
case  study.  1 


1.  Introduction 

Analyzing  security  policies  is  a  critical  step  towards  en¬ 
gineering  secure  software  systems.  Secure  software  sys¬ 
tems  are  often  designed  to  separate  security  policy  from 
security  mechanism  [1]  in  order  to  provide  the  flexibility 

*The  views  expressed  in  this  article  are  those  of  the  author  and  do  not 
reflect  the  official  policy  or  position  of  the  United  States  Air  Force,  De¬ 
partment  of  Defense,  or  the  U.S.  Government. 


to  address  dynamic  changes  in  security  requirements  over 
the  course  of  a  software  system’s  lifecycle.  The  software 
components  that  comprise  critical  systems  often  endure  ex¬ 
tensive  testing  if  not  more  rigorous  measures  such  as  formal 
methods.  However,  poor  policy  design  is  an  equally  grave 
hazard.  It  is  critical  to  verify  that  the  policy  as  stated  (or  at 
least  the  parts  of  it  under  one’s  control)  meets  ones  intended 
policy  objectives. 

Trust  management  (TM)  is  a  type  of  security  policy  con¬ 
cerned  with  reasoning  about  delegation  of  access  control 
in  software  systems  [1,  9].  Delegation  is  the  key  aspect 
of  TM  as  it  addresses  the  problem  of  scalability  in  tradi¬ 
tional  access  control  systems.  In  a  traditional  system,  ac¬ 
cess  control  is  maintained  by  a  centralized  authority.  In  a 
TM  system  access  rights  are  derived  as  a  consequence  of 
a  global  policy  state  that  consists  of  delegation  statements 
authored  by  principals  in  the  system,  some  of  whom  own 
resources.  The  global  policy  state  changes  whenever  a  prin¬ 
cipal  in  the  system  adds  or  removes  one  of  his  policy  state¬ 
ments.  Whereas  this  approach  provides  a  high  degree  of 
scalability  by  obviating  the  need  for  centralized  authority, 
it  also  introduces  management  problems  of  its  own,  since 
portions  of  the  policy  state  are  authored  by  untrusted  enti¬ 
ties.  Policy  authors  need  analysis  tools  that  can  determine 
whether  critical  policy  requirements  can  be  compromised 
by  untrusted  and  semi-trusted  principals  in  the  system. 

Whereas  many  formal  methods  may  be  too  costly  for 
this  purpose,  we  seek  lightweight  approaches  [7].  Such  ap¬ 
proaches  work  with  existing  notations  and  are  highly  au¬ 
tomated,  often  with  established  tool  support.  In  particular, 
here  we  explore  the  use  of  model  checking. 

Several  recent  papers  examine  the  applicability  of  model 
checking  as  a  means  to  verify  security  properties  in  poli¬ 
cies  of  centralized  systems  [3,  6,  10].  Our  study  is  based 
on  the  security  analysis  problem  introduced  and  formalized 
in  [9],  which  considers  whether  queried  properties  hold  in 
all  states  that  are  reachable  through  changes  made  by  un¬ 
trusted  and  semi-trusted  principals.  It  is  based  on  the  role- 


based  trust  management  language,  RT  [8].  We  present  a 
translation  of  RT  policy  to  an  SMV  model  and  report  on  the 
feasibility  of  verifying  security  properties  on  this  model.  To 
the  best  of  our  knowledge,  this  is  the  first  examination  of 
model  checking  in  verification  of  TM  policies. 

The  structure  of  this  paper  is  as  follows.  Section  2  de¬ 
scribes  the  RT  language  and  the  expensive  complexity  of 
role  containment  analysis.  Section  3  provides  a  brief  back¬ 
ground  of  model  checking.  Section  4  outlines  the  transla¬ 
tion  of  an  RT  policy  to  an  SMV  model  and  provides  justi¬ 
fication  for  reduction  techniques  used  to  scope  the  size  of 
the  resulting  model.  Section  5  illustrates  this  technique  in  a 
case  study.  Section  6  comments  on  related  and  future  work, 
and  we  conclude  in  Section  7. 

2.  The  RT  Policy  Language 

The  role-based  trust  management  policy  language  RT 
was  designed  to  support  highly  decentralized  attribute- 
based  access  control  [8].  It  enables  resource  providers  to 
make  authorization  decisions  about  resource  requesters  of 
whom  they  have  no  prior  knowledge.  This  is  achieved  by 
delegating  authority  for  characterizing  principals  in  the  sys¬ 
tem  to  other  entities  that  are  in  a  better  position  to  provide 
the  characterization.  For  instance,  to  grant  discounted  ser¬ 
vice  to  students,  a  resource  provider  might  delegate  to  uni¬ 
versities  the  authority  to  identify  students  and  delegate  to 
accrediting  boards  the  authority  to  identify  universities. 

A  significant  problem  that  policy  authors  face  in  this 
context  is  that  of  determining  the  extent  of  their  exposure 
through  delegation  to  untrusted  or  semi-trusted  principals. 
The  security  analysis  problem  [9]  in  this  context  consists  of 
determining  whether  changes  made  by  principals  that  are 
not  fully  trusted  could  cause  certain  policy  objectives  to 
become  violated.  One  example  of  the  problem  would  ask 
whether  anyone  outside  the  organization  could,  because  of 
changes  made  by  principals  outside  the  inner  circle,  gain 
access  to  the  organization’s  sensitive  data.  In  this  section, 
we  summarize  RT  and  the  security  analysis  of  it. 

2.1.  Brief  Review  of  RT  Syntax  &  Seman¬ 
tics 

In  RT,  all  principals  are  able  to  define  their  own  roles 
and  to  assign  other  principals  to  them.  A  role  owner  can  do 
this  by  issuing  authenticatable,  role-defining  statements  of  a 
few  different  types.  To  her  own  roles,  she  can  add  a  specific 
principal  or  she  can  add  the  members  of  another  role.  In  the 
latter  case,  she  is  delegating  authority  to  the  owner  of  the 
other  role.  Delegating  authority  to  another  owner  can  occur 
in  two  ways.  First  she  can  identify  a  specific  principal  as  a 
delegate.  Secondly,  she  can  identify  a  collection  of  princi¬ 
pals  as  delegates  such  that  these  principals  are  grouped  by 


Type 

Syntax 

Description 

Type  I 

A.r  <—  D 

Simple  Member 

Type  II 

A.r  <—  B.r\ 

Simple  Inclusion 

Type  III 

A.r  <—  B.r\.r2 

Linking  Inclusion 

Type  IV 

A.r  <—  B.r\  D  C.r2 

Intersection  Inclusion 

Figure  1.  RT  Statements 


a  role.  Set  intersection  and  union  are  also  both  available  for 
role  definition. 

The  RT  language  consists  of  two  primary  objects  called 
roles  and  principals.  A  principal  is  an  entity  such  as  a  per¬ 
son  or  software  agent.  Each  role  can  be  described  as  a  set 
of  principals  and  is  of  the  form  “principal. role_name”.  One 
interpretation  of  this  role  is  that  the  principal  considers  the 
members  (also  principals)  of  this  role  to  have  an  attributed 
denoted  by  the  role  name.  For  example,  Alice. friend  may 
be  a  role  that  contains  the  principals  whom  Alice  considers 
friends. 

The  basic  RT  language  consists  of  four  types  of  state¬ 
ments  as  shown  by  Figure  1  [9],  Type  I  statements  directly 
introduce  individual  principals  to  roles.  A  given  principal 
can  only  show  up  in  a  role  if  it  was  introduced  by  a  Type  I 
statement.  For  example,  Alice  friend  <—  Bob  identifies  Bob 
as  a  friend  of  Alice.  Type  II  statements  express  a  form  of 
delegation  that  describes  the  implication  that  if  principals 
are  in  one  role,  then  they  are  in  another  role  as  well.  For 
example,  the  statement  Alice  friend  Bob  friend  describes 
the  situation  in  which  if  a  principal  is  a  friend  of  Bob,  then 
they  are  also  a  friend  of  Alice.  Type  III  statements  provide 
a  mechanism  to  delegate  to  all  members  of  a  role.  For  ex¬ 
ample,  the  statement  Alice  friend  <—  Bobfriendfriend  says 
that  any  friend  of  Bob’s  friends  is  also  a  friend  of  Alice.  It 
does  not  imply  that  Alice’s  friends  include  Bob’s  friends. 
Finally,  Type  IV  statements  introduce  intersection  such  that 
a  principal  must  be  in  two  roles  in  order  to  be  included. 
For  example,  Alice  friend  *—  Bob  friend  Pi  Carl  friend  says 
that  only  those  principals  who  are  both  Bob’s  friends  and 
Carl’s  friends  are  introduced  into  the  set  of  Alice’s  friends. 
Note  that  disjunction  is  provided  through  multiple  state¬ 
ments  defining  the  same  role. 

In  this  paper  we  use  certain  terms  to  describe  specific 
pieces  of  the  policy.  The  left  hand  side  of  the  arrow  is 
called  the  defined  role.  In  regards  to  Type  III  statements,  the 
base-linked  role  is  the  role  that  contains  the  principals  upon 
which  the  linking  role  is  applied.  Closely  related  are  the 
sub-linked  roles  which  are  the  roles  produced  by  the  linking 
role.  Thus  in  the  case  of  A.r  <—  B.r\.r2 ,  the  role  B.r\  is 
the  base-linked  role  and  every  role  such  as  A.r2,  Rr2  and 
so  on  are  the  sub-linked  roles. 


2.2.  RT  Policy  Analysis 

Policy  analysis  examines  whether  or  not  properties  such 
as  availability,  safety,  liveness  and  mutual  exclusion  hold 
[9].  Availability  asks  if  a  principal  always  has  access  to  a  re¬ 
source,  whereas  safety  is  concerned  with  testing  if  the  mem¬ 
bership  of  role  is  bounded  by  a  set  of  principals.  Liveness 
asks  if  it  is  possible  to  reach  a  situation  where  no  principals 
have  access  to  a  resource.  Mutual  exclusion  is  concerned 
with  testing  for  separation  of  duty  such  that  the  member¬ 
ship  of  two  roles  do  not  intersect. 

These  properties  are  tested  with  respect  to  restrictions. 
Restrictions  provide  a  tool  to  help  reason  about  trust  and 
delegation  by  acting  as  a  control  on  how  the  policy  may 
change  over  time.  Given  an  initial  policy  with  no  restric¬ 
tions,  each  statement  may  be  removed  and  new  statements 
may  be  added.  If  we  wish  to  limit  how  roles  are  defined, 
we  may  add  growth  and  shrink  restrictions.  Growth  re¬ 
strictions  consist  of  a  list  of  roles  that  are  not  allowed  to 
be  defined  by  any  statement  other  than  those  present  in  the 
initial  policy.  Shrink  restrictions  consist  of  a  list  of  roles 
whose  defining  statements  may  not  be  removed.  For  ex¬ 
ample,  given  the  statement  Alice.friend  +—  Bob. friend 
in  the  initial  policy,  and  Alice.friend  is  shrink  restricted, 
then  we  can  guarantee  that  Bob’s  friends  will  always  be  Al¬ 
ice’s  friends.  If  this  same  role  were  also  growth  restricted 
and  there  were  no  other  statements  defining  it  in  the  initial 
policy,  then  we  may  say  that  Alice  cannot  have  any  friends 
other  than  those  of  Bob’s  friends.  Restrictions  could  repre¬ 
sent  either  system-enforced  rules,  or  identify  the  principals 
of  such  roles  as  entities  that  can  be  trusted  to  make  safe 
policy  changes.  By  identifying  the  smallest  set  of  restric¬ 
tions,  one  can  also  identify  the  set  of  principals  that  must  be 
trusted  in  order  for  the  property  to  hold. 

The  aforementioned  properties  can  be  verified  in  poly¬ 
nomial  time,  but  there  is  one  property  that  is  much  more 
expensive  to  verify  and  the  focus  of  this  paper.  Role  con¬ 
tainment  asks  if  one  role  is  a  subset  of  another  role.  We 
want  to  know  if  those  principals  in  one  role  (possibly  with 
access  to  a  resource)  are  also  always  in  another  role  (possi¬ 
bly  with  access  to  another  resource).  Li  et.  al.  [9]  proved 
an  upper  bound  of  co-NEXP  on  the  time  required  to  an¬ 
swer  this  query,  whereas  the  other  properties  can  be  veri¬ 
fied  in  polynomial  time.  The  difference  in  complexity  in¬ 
volves  the  monotonic  nature  of  the  language.  Once  a  prin¬ 
cipal  is  included  in  a  role  from  one  source,  it  cannot  be  re¬ 
moved.  There  are  no  negative  statements  in  the  sense  that  no 
statement  has  the  effect  of  removing  principals  from  roles. 
This  allows  properties  such  as  availability,  safety,  liveness 
and  mutual  exclusion  to  be  evaluated  by  simply  producing 
the  “maximal  reachable  state’’  or  “minimal  reachable  state” 
[9].  However,  containment  properties  cannot  be  determined 
solely  by  maximal  or  minimal  reachable  states.  Instead,  we 
must  examine  all  of  the  states  that  lie  between  these  two  ex¬ 


tremes.  The  purpose  of  this  work  is  to  examine  these  states 
for  role  containment  using  model  checking. 

3.  Model  Checking 

Model  checking  [2]  is  an  automated  verification  tech¬ 
nique  that  builds  a  finite  model  of  a  system  and  exhaustively 
explores  the  state  space  of  the  model  to  determine  if  desired 
properties  hold  in  the  model.  In  the  case  that  a  property  is 
false,  a  counterexample  will  be  produced  to  show  an  error 
trace,  which  can  be  used  to  fix  the  model  or  the  property 
specification. 

SMV  [1 1]  is  a  BDD-based  model  checking  tool.  Mod¬ 
els  are  represented  using  variables  and  their  assignments  in 
each  step,  and  properties  are  specified  as  temporal  logic  [12] 
formula.  SMV  provides  built-in  finite  data  types,  such  as 
boolean,  enumerated  type,  integer  range,  arrays,  and  bit 
vectors.  In  SMV,  state  variables  are  assigned  initial  val¬ 
ues  and  next  values  in  every  SMV  step:  a  variable  jc’s  value 
in  the  next  state,  next(;c),  is  either  the  value  of  an  expres¬ 
sion  in  the  current  state  or  the  value  of  an  expression  in  the 
next  state.  Expression  operators  and  — ►  represent 

logical  operators  “not”,  “and”,  “or”,  and  “implies”,  respec¬ 
tively.  Comments  follow  the  symbol  “- 

The  state  of  the  system  is  determined  by  the  values  of  all 
state  variables.  The  transition  relation  is  defined  by  the  set 
of  next  assignments  which  execute  concurrently  in  a  step  to 
determine  the  next  state  of  the  model.  SMV  allows  nonde- 
terministic  assignments,  i.e.,  the  value  of  a  variable  is  cho¬ 
sen  arbitrarily  from  the  set  of  possible  values.  SMV  also 
supports  derived  statements  (macros),  which  are  replaced 
by  their  definitions,  so  they  do  not  increase  a  system’s  state 
space.  In  this  paper,  macros  are  intensively  used  in  SMV 
models  resulting  from  our  translation. 

The  properties  we  want  to  check  are  called  specifica¬ 
tions,  which  are  expressed  in  temporal  logic.  Temporal 
logic  is  a  language  for  expressing  properties  related  to  a  se¬ 
quence  of  states  in  terms  of  temporal  logic  operators  and 
logic  connectives  (e.g.,  A  and  V).  Temporal  operators  X,  F, 
and  G  represent  next  state,  some  future  state,  and  all  future 
states,  respectively.  For  example,  Gp  means  that  property  p 
is  always  true  in  all  possible  states. 

4.  Modeling  RT  Policies 

RT  policies  are  allowed  to  change  over  time  as  state¬ 
ments  are  added  or  removed  according  to  growth  and  shrink 
restrictions.  This  dynamic  behavior  can  be  described  as 
transitions  from  one  policy  state  to  another,  where  each  state 
is  defined  by  its  policy  statements.  We  are  interested  in  ex¬ 
amining  security  properties  at  each  state  in  order  to  prove 
that  these  properties  hold  throughout  the  changes.  Model 
checking  is  appropriate  for  our  goal  as  it  can  quickly  find 


counterexamples  when  properties  fail  to  hold.  The  follow¬ 
ing  sections  describe  the  pre-processing  and  translation  nec¬ 
essary  to  verify  RT  policies  using  a  model  checking  ap¬ 
proach. 

4.1.  Maximum  Relevant  Policy  Set 

Given  an  initial  policy  and  a  set  of  restrictions,  it  is  diffi¬ 
cult  to  predict  what  additional  statements  containing  roles 
and  principals  may  be  added  to  the  policy  in  the  future. 
Whereas  an  RT  policy  is  not  constrained  by  the  number  of 
statements,  roles  or  principals  it  can  contain,  model  check¬ 
ing  requires  a  finite  state  space.  This  is  achieved  by  defin¬ 
ing  a  maximum  relevant  policy  set  (MRPS).  The  MRPS  is 
the  maximum  set  of  policy  statements  that  may  contribute 
to  the  outcome  of  a  particular  query  given  an  initial  pol¬ 
icy.  Thus  the  MRPS  is  built  with  respect  to  a  query  and 
contains  all  initial  policy  statements  as  well  as  additional 
Type  I  statements.  The  Type  I  statements  are  necessary  in 
order  to  introduce  additional  principals  into  the  roles.  In¬ 
tuitively,  any  statement  added  to  a  policy  can  be  re-written 
as  a  (possibly  empty)  set  of  Type  I  statements,  as  demon¬ 
strated  in  [9].  These  principals  introduced  by  the  Type  I 
statements  are  representative  of  all  possible  principals  and 
a  certain  number  of  them  are  necessary  in  order  to  verify 
role  containment.  As  previously  shown  [9],  if  the  contain¬ 
ment  property  does  not  hold,  then  the  counterexample  state 
will  have  at  most  M  =  2^*  principals  over  0(M2N)  state¬ 
ments,  where  S  is  the  set  of  significant  roles  and  N  is  the 
number  of  initial  policy  statements.  A  significant  role  is 
defined  as  one  of  the  following: 

1 .  The  superset  role  in  a  role  containment  query. 

2.  The  base-linked  role  of  a  Type  III  statement. 

3.  Both  intersected  roles  on  the  RHS  of  a  Type  IV  state¬ 
ment. 

To  construct  the  MRPS,  we  first  place  all  the  principals 
on  the  RHS  of  Type  I  statements  from  the  initial  policy  into 
set  Princ.  Then  we  calculate  how  many  additional  princi¬ 
pals  are  needed  using  the  upper  bound  described  by  M.  We 
place  this  number  of  additional  principals  into  Princ.  Next 
we  build  the  set  of  roles  Roles  to  include  all  of  the  roles 
from  the  initial  policy  and  query  as  well  as  those  roles  con¬ 
structed  from  the  cross  product  of  principals  Princ  and  link 
role  names.  Finally,  we  construct  new  Type  I  statements 
from  the  cross  product  of  Roles  and  Princ.  These  statements 
along  with  all  of  the  initial  policy  statements  constitute  the 
MRPS.  In  addition  it  is  useful  to  identify  the  Minimum  Rel¬ 
evant  Policy  Set  as  the  set  of  non-removable  initial  policy 
statements.  It  identifies  which  statements  are  permanently 
included  in  our  model. 

Consider  the  example  in  Figure  2.  Although  the  number 
of  Type  I  statements  that  needed  to  be  added  seems  large 


Initial  Policy 

MRPS 

A.r  <—  B.r 

A.r  <—  B.r 

E.s  4—  F 

A.r  <—  C.r.s 

A.r  <—  C.r.s 

E.s  4—  G 

A.r  <—  B.r  D  C.r 

A.r  <—  B.r  Pi  C.r 

E.s  4-  H 

A.r  <—  E 

F.s  4—  E 

A.r  <—  F 

F.s  4-  F 

A.r  4-  G 

F.s  4-  G 

A.r  4—  H 

F.s  4-  H 

B.r  <—  E 

G.s  4—  E 

B.r  4-  F 

G.s  4—  F 

B.r  4—  G 

G.s  4-  G 

B.r*-  H 

G.s  4—  H 

C.r  *-E 

H.s  4—  E 

C.r  4—  F 

H.s  *-  F 

C.r  4-  G 

H.s  4—  G 

C.r  4-  H 

E.s  *-  E 

H.s  *-  H 

Figure  2.  Initial  Policy  (no  restrictions)  & 
Query:  A.r  □  B.r  vs.  MRPS 


compared  to  the  original  policy,  growth  restrictions  may  re¬ 
duce  the  size  of  the  MRPS  because  we  will  not  be  able  to 
add  new  principals  to  certain  roles.  In  this  way,  growth  re¬ 
strictions  are  accounted  for  in  the  model.  Statements  defin¬ 
ing  growth  restricted  roles  (other  than  those  in  the  initial 
policy)  are  simply  not  included  into  the  MRPS.  Shrink  re¬ 
strictions  are  accounted  for  in  next  state  relations  in  Section 
4.2.3. 

4.2.  RT  to  SMV  Translation  Rules 

The  translation  from  an  RT  policy,  restrictions,  and  query 
to  an  SMV  model  is  comprised  of  five  steps  described  in  the 
following  subsections. 

4.2.1.  Build  MRPS  &  SMV  Model  Header 

Preprocessing  the  initial  policy  into  the  MRPS  is  the  first 
step  of  this  process  as  it  provides  a  finite  number  of  state¬ 
ments  and  principals  to  be  translated  into  the  SMV  model. 
We  detail  the  MRPS  in  comments  at  the  head  of  the  file 
for  easy  indexing  reference.  This  reference  provide  readers 
with  a  quick  understanding  of  what  each  bit  position  repre¬ 
sents.  Information  in  the  header  should  include  the  original 
policy,  restrictions,  the  query  as  well  as  a  list  of  all  roles  and 
all  principals  considered  in  this  model. 

4.2.2.  Build  SMV  Data  Structures 

Each  model  contains  one  bit  vector  representing  all  of  the 
statements  in  the  MRPS  and  additional  role  bit  vectors  rep¬ 
resenting  each  role.  The  size  of  the  statement  bit  vector  is 
the  size  of  the  MRPS  and  the  size  of  each  role  bit  vector 
is  equivalent  to  the  number  of  principals  considered.  For 


—  bit  for  each  statement 
statement  :  array  0..33  of  boolean; 

—  bit  for  each  principal  per  role 
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Figure  3.  Example  SMV  Data  Structures  from 
Fig.  2  MRPS 


example,  in  Figure  2,  the  number  of  principals  considered 
is  four  and  thus  every  role  will  have  four  bits  as  in  Figure 
3.  We  keep  the  naming  convention  from  the  RT  policy  and 
reuse  the  original  role,  linking  role  and  principal  names  with 
the  exception  that  we  remove  the  dot  (.)  since  in  SMV  this 
operator  has  a  specific  and  unrelated  function. 

4.2.3.  Initialization  &  Next  State  Relations  of  Statement 

Bit  Vector 

Initialization  of  state  variables  reflects  the  initial  policy 
state.  As  such,  each  bit  in  the  statement  bit  vector  is  ini¬ 
tialized  to  true  if  its  corresponding  policy  statement  can 
be  found  in  the  initial  policy.  Otherwise  the  bit  is  set  to 
false  indicating  its  corresponding  statement  is  not  included 
in  the  initial  policy.  A  special  case  exists  when  a  statement 
is  shrink-restricted  (the  defined  role  is  non-removable)  and 
included  in  the  initial  policy.  In  these  cases,  the  bit  is  de¬ 
fined  as  permanent  indicating  that  the  policy  statement  it 
indexes  cannot  be  removed  from  any  policy  state.  Perma¬ 
nent  bits  do  not  contribute  to  the  state  space.  Transitions 
from  one  state  to  another  are  accomplished  by  leaving  non¬ 
permanent  statement  bits  to  remain  unbound.  By  unbound, 
we  mean  that  the  bit  can  be  nondeterministically  assigned 
either  true  or  false,  allowing  the  model  checker  to  find  a 
state  of  bits  such  that  the  property  does  not  hold.  An  ex¬ 
ample  of  initialization  and  next  state  relations  is  Figure  4. 
While  this  strategy  is  sufficient  to  look  for  counterexamples, 
certain  optimizations  can  be  used  to  reduce  the  state  space 
depending  on  the  structure  of  the  policy.  We  discuss  these 
in  Section  4.6. 

4.2.4.  Build  Role  Derived  Statements 

Roles  are  defined  in  terms  of  policy  statements  and  other 
roles.  When  modeling  this  relationship,  we  use  derived 
variables  since  the  state  of  the  policy  is  defined  in  terms 
of  only  policy  statements,  not  roles.  A  derived  variable  in 
SMV  is  a  function  of  state  variables  and  other  derived  vari- 


init (statement | 

[0]) 

:=  0; 

init (statement | 

[1]) 

:  =  0; 

statement [2]  := 

■  1; 

next  (statement | 

[0]) 

:=  {0, 

i}; 

next  (statement | 

[i]) 

:=  {0, 

1}; 

Figure  4.  Example  SMV  Initialization  &  Next 
State  Relations 


ables.  The  translation  is  summarized  in  Figure  5.  The  fol¬ 
lowing  describes  the  translation  of  each  type  of  statement. 

We  modeling  a  role  with  multiple  statements  by  taking  the 
logical  or  of  the  definitions  below. 

Type  I  policy  statements  are  expressed  in  the  model  as 
direct  associations  between  roles  and  statements.  Thus  the 
RT  statement  A.r  <—  B  that  is  indexed  as  statement  0  in 
our  MRPS  is  expressed  as  Ar[l]  :=  statement[ 0];  in  SMV 
where  bit  position  1  in  all  roles  corresponds  to  B.  If  state¬ 
ment  0  exists  in  a  policy  state,  then  B  is  a  member  of  A.r. 

Type  II  policy  statements  are  expressed  as  a  relation  be¬ 
tween  two  roles.  Thus  the  statement  A.r  <—  B.r  that 
is  indexed  as  statement  1  in  our  MRPS  is  expressed  as 
Ar[i\  :=  statement[  1]  Sz  Br[i]\  for  i  —  0  ...n  princi¬ 
pals.  In  many  cases,  we  can  use  the  shorthand  notation 
Ar  :=  statement[  1]  &  Br  which  is  equivalent. 

Type  III  policy  statements  are  more  complex  since 
they  require  testing  each  of  the  sub-linked  roles. 
Given  the  statement  A.r  <—  B.r.s  that  is  indexed 
as  statement  2  in  our  MRPS,  we  express  it  as  Ar[i]  := 
statement[ 2]  Sz  ((J3r[0]  Sz  )  | . . .  |  (Br[j]  Sz  jth  role[i\))\ 
for  i  =  0  ...  n  principals  and  j  sub-roles. 

Finally,  Type  IV  policy  statements  are  expressed  as  a  re¬ 
lation  between  three  roles.  The  statement  A.r  <—  B.rHC.r 
that  is  indexed  as  statement  3  in  our  MRPS  is  expressed  as 
Ar[i]  :=  statement [3]  Sz  Br[i\  Sz  Cr[i]\  for  i  =  0. .  .n 
principals.  Again,  we  may  use  the  shorthand  notation 
Ar  :=  statement [3]  Sz  Br  Sz  Cr\  where  applicable. 

4.2.5.  Build  Specification 

In  model  checking,  the  specification  is  the  property  we  wish 
to  test.  The  security  analysis  of  RT  may  wish  to  test  such 
properties  as  availability,  safety,  role  containment  and  mu¬ 
tual  exclusion.  Our  approach  allows  each  of  these  properties 
to  be  tested  and  provides  counterexamples  if  the  property 
does  not  hold.  Consider  the  example  in  Figure  6  where  A.r 
and  B.r  are  two  roles  and  the  MRPS  considers  principals  C, 

D  and  F. 

Note  that  the  linear  temporal  logic  (LTL)  operator  G  is 
used  to  signify  that  all  states  are  required  to  hold  this  prop¬ 
erty.  Existential  properties  can  also  be  tested  using  the  nega¬ 
tion  of  G  or  through  the  LTL  operator  F. 
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Figure  5.  RT  Statement  to  SMV  Statement 


Property 

RT  Query 

SMV  Specification 

Notes 

Availability 

Safety 

Containment 
Mutual  Exclusion 

A.r  □  {C,  D}  Always 
{C,D}  □  A.r  Always 
A.r  □  B.r  Always 

A.r  ®  B.r  Always 

assert  G  (Ar[0]  &  Ar[  1]) 

assert  G  (~  Ar[2]) 
assert  G  ( Ar  \  Br  =  Ar) 
assert  G  (Ar  &  Br  =  0) 

C  and  D  in  A.r 

E  not  in  A.r 

Nothing  new  in  B.r 
No  intersection 

Figure  6.  RT  Queries  to  SMV  Specifications 


4.3.  State  Space 

The  state  of  the  policy  is  defined  by  the  combination  of 
policy  statements  from  the  MRPS.  Intuitively,  the  transition 
from  one  policy  state  to  another  is  defined  as  the  addition  or 
removal  of  policy  statements.  This  is  achieved  by  allowing 
the  model  checker  to  freely  assign  flip  bits  in  the  statement 
bit  vector.  While  this  statement  bit  vector  encodes  the  state 
of  the  policy,  it  alone  is  not  sufficient  to  test  the  containment 
query  since  both  role  memberships  must  be  computed  based 
on  which  statements  are  included  in  a  given  state.  Comput¬ 
ing  role  membership  can  be  performed  in  polynomial  time 
(that  is  0(p3),  where  p  is  the  number  of  policy  statements) 
[9]  as  a  separate  function,  however  this  may  be  expensive 
considering  the  number  of  states  that  this  function  needs  to 
be  applied.  A  more  efficient  approach  is  to  encode  the  roles 
as  derived  variables  (again  bit  vectors)  in  the  model  such 
that  as  the  state  of  the  policy  changes,  the  membership  of  all 
the  roles  are  updated.  The  derived  variables  represent  role 
membership  where  each  element  position  represent  whether 
or  not  a  principal  is  included  in  that  role.  The  membership 
of  the  roles  is  then  used  to  test  for  role  containment.  Al¬ 
though  these  derived  variables  may  seemingly  increase  the 
state  space,  they  in  fact  have  no  effect  on  it  because  they 
are  not  left  unbound  for  the  model  checker  to  manipulate.  It 
should  be  noted  that  it  is  possible  to  create  an  MRPS  with 
a  state  space  so  large  that  role  containment  cannot  be  veri¬ 
fied  in  any  reasonable  amount  of  time.  In  model  checking 
terms,  this  is  called  the  state  explosion  problem.  Thus  in 
cases  where  the  role  containment  property  holds,  it  is  pos¬ 
sible  that  the  specification  cannot  be  verified  in  an  amount 
of  time  that  is  useful  to  the  policy  author.  However,  the 
redeeming  feature  of  a  model  checking  approach  is  that  if 
the  property  does  not  hold,  then  it  may  be  found  in  a  short 
amount  of  time. 


4.4.  Role  Dependency  Graph 

A  role  dependency  graph  (RDG)  is  a  useful  tool  for 
visually  depicting  and  analyzing  role-to-role  and  role-to- 
principal  relationships.  The  RDG  also  provides  a  means  of 
detecting  circular  dependencies.  It  is  a  directed  graph  where 
each  node  represents  a  role,  a  linked  role,  the  conjunction 
of  two  roles,  or  a  principal.  Each  edge  represents  a  specific 
policy  statement  and  is  labeled  by  its  index  in  the  MRPS. 
An  edge  is  understood  to  mean  the  source  node  is  depen¬ 
dent  on  the  destination  node,  and  its  label  is  the  condition 
of  the  edge’s  existence.  Nodes  representing  roles  may  have 
many  edges,  each  representing  a  different  definition  of  that 
role. 

Type  I  statements  are  always  illustrated  as  an  edge  be¬ 
tween  a  role  node  and  a  principal  node.  Principal  nodes 
are  always  leaves  in  the  RDG  because  they  cannot  contain 
anything.  Type  II  statements  are  represented  by  an  edge  be¬ 
tween  two  role  nodes. 

Type  III  and  IV  statements  are  expressed  with  unique 
structures.  Type  III  statements  use  an  edge  representing  a 
policy  statement  from  role  node  to  a  linked  role  node,  but 
then  also  use  a  dashed  edge  from  the  linked  role  node  to 
other  role  nodes  representing  sub-linked  roles.  The  purpose 
of  the  dashed  edge  is  to  visually  identify  the  condition  that  a 
principal  is  in  the  base-linked  role.  These  edges  are  labeled 
with  the  principal’s  name.  Figure  7  illustrates  this  structure. 

Type  IV  statements  use  an  edge  representing  a  policy 
statement  from  a  role  node  to  the  conjunction  of  two  roles, 
but  then  uses  an  intermediate  edge  to  show  the  relationship 
between  the  conjunctive  node  and  the  roles  from  which  it  is 
composed.  These  edges  are  labeled  as  it  for  intermediate, 
do  not  represent  policy  statements  and  always  exist.  Figure 
8  demonstrates  this  structure. 

While  the  role  dependency  graph  can  be  used  to  deter- 


Figure  7.  Type  III:  A.r  <-  B.r.s 


Figure  9.  Circular  Dependency  with  Type  II 
Statements 


Figure  8.  Type  IV:  A.r  <-  B.r  n  C.r 

mine  membership  of  roles,  it  can  also  provide  some  insight 
into  the  role  containment  query.  For  example,  if  a  path  of 
non-removable  edges  exists  from  a  superset  to  a  subset,  then 
we  can  guarantee  that  the  containment  relationship  is  al¬ 
ways  true.  This  can  be  described  as  a  “structural”  relation¬ 
ship.  However,  containment  can  also  occur  through  other 
means  that  we  describe  as  an  “ad  hoc”  relationship.  A  good 
example  of  this  is  the  situation  where  two  roles  are  tested  for 
containment,  but  they  exist  in  separate,  unconnected  graphs. 
These  ad  hoc  relationships  are  often  the  real  challenge  of 
answering  containment  queries. 

4.5.  Circular  Dependencies 

The  role  dependency  graph  is  necessary  to  detect  circular 
dependencies  in  an  RT  policy.  The  RT  language  places  no 
restrictions  on  self  referencing  statements  such  as  A.r  <—  A.r 
or  circular  referencing  such  as  A.r  *—  B.r ,  B.r  <—  A.r.  In  the 
latter  case,  this  is  interpreted  as  A.r  is  equivalent  to  B.r  if 
and  only  if  both  statements  are  non-removable.  All  circular 
references  must  be  removed  before  translation  to  a  model 
since  SMV  cannot  handle  circular  definitions. 

4.5.1.  Detecting  Circular  Dependencies 

Since  there  are  situations  where  circular  dependencies  cause 
significant  problems,  a  means  to  detect  them  is  necessary. 


The  two  approaches  used  are  well-formed  syntax  checks 
and  graph  cycle  detection.  The  first  approach  detects  cycles 
using  syntax  check  as  each  policy  statement  is  processed. 
For  example,  if  a  role  is  defined  by  itself,  then  we  can  safely 
remove  this  statement  since  it  doesn’t  contribute  anything  to 
the  query.  It  is  easy  to  perform,  however  it  only  catches  self- 
referencing  cycles.  The  second  and  more  general  approach 
detects  cycles  across  any  number  of  statements  using  tradi¬ 
tional  depth  first  search.  In  these  cases,  it  is  not  sufficient  to 
simply  remove  a  statement.  In  these  cases  we  must  perform 
dependency  unrolling. 

4.5.2.  Unrolling  Circular  Dependencies 

The  relationship  among  roles  can  be  equivalently  repre¬ 
sented  using  conditions  of  policy  statements.  Policy  state¬ 
ments  are  neither  modified  nor  added  or  removed  in  order 
to  accomplish  this.  To  understand  how  this  works,  let  us 
consider  how  to  unroll  the  previous  example  involving  A.r 
and  B.r.  The  left  graph  of  Figure  9  illustrates  how  two 
Type  II  statements  might  form  a  circular  dependency.  The 
right  graph  in  the  figure  demonstrates  the  unrolled  version. 
Edges  represent  conditions  upon  which  the  dependency  re¬ 
lies.  Thus  the  role  B.r  will  include  expl  if  and  only  if  state¬ 
ments  1  and  2  are  included  in  the  policy  state. 

Circular  dependencies  involving  Type  III  statements  can 
occur  frequently.  Two  cases  involving  Type  III  statements 
may  cause  a  circular  dependency.  The  first  occurs  in  an  ex¬ 
plicitly  recursive  statement  such  as  when  the  base-linked 
role  is  any  parent  to  the  linked  role  in  the  RDG.  These 
cases  require  extensive  unrolling  and  for  brevity  are  not 
shown  here.  The  second  occurs  when  any  of  the  sub-linked 
roles  are  any  parent  to  the  linked  role.  Here  the  circular 
dependency  can  be  removed  using  the  unrolling  approach 
described  above,  as  illustrated  by  Figure  10.  In  this  case, 
the  conditionals  noted  on  the  edges  include  not  only  policy 
statement  indices,  but  also  actual  principals  that  must  exist 
in  the  base-linked  role  in  order  for  the  dependency  to  exist. 
In  the  example  demonstrated  by  Figure  10,  B. r  will  include 


Figure  10.  Circular  Dependency  with  Type  III 
Statements 


Figure  11.  Circular  Dependency  with  Type  IV 
Statements 


exp l  if  and  only  if  statements  0  and  3  are  included  in  the 
policy  state,  as  well  as  C.r  contains  the  principal  A. 

Finally,  Type  IV  statements  that  introduce  circular  de¬ 
pendencies  when  one  or  both  of  the  intersected  roles  is  a 
parent  in  the  RDG.  Again  unrolling  is  found  effective  when 
coupled  with  the  realization  that  A.r  <—  A.r  Pi  B.r  does  not 
contribute  anything  unique  to  A.r .  In  fact,  this  is  a  base  case 
such  that  if  the  circular  dependency  exists  in  that  form  then 
it  can  be  safely  removed.  Figure  1 1  illustrates  an  example 
of  circular  dependency  involving  Type  IV  statements.  Here 
the  only  thing  contributing  to  A.r  through  B.r  is  exp2  and 
not  A.r  &  C.r. 

For  the  sake  of  completion,  note  that  Type  I  statements 
cannot  contribute  to  circular  dependency.  Also,  statements 
such  as  A.r  A.r  can  safely  be  removed  since  it  doesn’t 
contribute  anything  new  into  A.r. 

4.6.  Chain  Reduction 

Certain  optimizations  can  be  incorporated  to  further  re¬ 
duce  the  state  space  by  recognizing  logically  equivalent 
states  with  respect  to  a  particular  role.  Consider  the  exam¬ 
ple  using  Type  II  statements  where  we  want  to  determine 
the  membership  of  A.r  in  Figure  12.  In  this  case,  there  are 
a  total  of  4  statements  and  24  =  16  states  possible.  If  state¬ 
ment  3  is  removed,  then  not  only  is  the  membership  of  D.r 
is  empty,  but  also  the  membership  of  A.r,  B.r ,  and  C.r.  Thus 
under  the  condition  that  statement  3  does  not  exist,  we  do 
not  need  to  check  the  eight  states  representing  combinations 
of  statements  0,  1  and  2.  This  is  handled  by  conditional 
statements,  one  example  of  which  is  Figure  13.  The  effec¬ 
tive  result  is  that  we  now  test  only  a  single  state  (the  empty 


policy)  if  statement  3  does  not  exist.  The  same  idea  can  be 
used  if  a  role  is  defined  by  multiple  policy  statements. 


Index 

Statement 

0 

A.r  <—  B.r 

1 

B.r  <—  C.r 

2 

C.r  <—  D.r 

3 

D.r  «—  E 

Figure  12.  Example  of  Chain  Reduction 


if (next (statement [3] ) ) 

next (statement [2 ] )  =  {0,1}; 
else 

next (statement [2] )  =  0; 

Figure  13.  Example  of  SMV  Chain  Reduction 

Type  III  and  Type  IV  statements  may  also  be  candidates 
for  this  reduction.  For  example,  given  the  Type  III  statement 
A.r  <—  B.r.s ,  if  the  base-linked  role  B.r  is  empty,  than 
the  linked  role  B.r.s  contributes  nothing  to  A.r.  Type  IV 
statements  are  often  easy  to  reduce  because  if  either  of  the 
intersected  roles  is  empty,  then  nothing  is  contributed  to  the 
defined  role  and  thus  we  can  force  the  other  intersecting  role 
to  also  be  empty.  A  series  of  these  conditions  may  occur 
leading  to  a  chain  reduction.  A  chain  reduction  may  imply 
many  logically  equivalent  states  are  able  to  be  checked  for 
a  property  with  only  a  single  test.  This  may  yield  a  smaller 
state  space. 


4.7.  Disconnected  Graphs 


Disconnected  graphs  are  non-connected  RDGs.  It  is  pos¬ 
sible  that  there  are  multiple  sub-graphs  in  a  system  that, 
while  not  connected  by  any  statements,  are  queried  for  con¬ 
tainment.  Our  current  translation  approach  works  correctly 
because  we  do  not  depend  on  if  the  queried  roles  are  con¬ 
nected  or  not.  However,  analyzing  the  RDG  may  provide 
insight  to  some  optimization.  For  example,  removing  sub¬ 
graphs  that  do  not  contain  the  roles  specified  in  the  query 
will  further  reduce  the  state  space. 

5.  A  Trust  Management  Case  Study 

Consider  the  access  control  policy  of  a  fictitious  com¬ 
pany  Widget  Inc.  Widget  has  a  marketing  strategy  and  an 
operations  plan  that  it  must  protect  from  competitors,  while 
at  the  same  accessible  to  those  employees  with  a  need  to 
know.  Some  properties  of  interest  are: 

1.  Is  the  marketing  strategy  and  operations  plan 

only  available  to  employees?  HR. employee  □ 

HQ.marketing,  HR.employee  □  HQ. ops 

2.  Does  everyone  who  has  access  to  the  operations  plan 
also  have  access  to  the  marketing  plan?  HQ.marketing 
□  HQ.  ops 

In  this  case,  the  significant  roles  are  HR.marketingDelg, 
HR.employee,  HR. managers,  HQ.specialPanel ,  and 
HR.researchDev  from  the  initial  policy  and  HQ.marketing 
from  the  second  query.  This  leads  to  a  maximum  of  64 
new  principals  added  to  the  model,  77  unique  roles  and  a 
total  of  4765  policy  statements,  13  of  which  are  permanent 
due  to  shrink  restrictions.  Note  that  not  all  of  the  roles 
are  growable.  Although  64  principals  is  the  upper  bound 
on  number  of  new  principals  added,  it  is  intuitive  that 
there  is  a  much  smaller  upper  bound,  which  is  the  topic 
of  future  work.  The  number  of  principals  needed  directly 
affects  how  many  Type  I  policy  statements  we  need.  Thus 
a  smaller  number  of  principals  yields  a  smaller  state  space. 
While  the  current  state  space  of  24765  is  quite  large,  SMV 
is  able  to  check  both  properties.  The  translation  from  RT 
took  about  9.9  s,  and  the  first  two  properties  were  verified 
using  SMV  in  approximately  400  ms.  The  third  was  found 
to  be  false  in  about  480  ms  with  a  counterexample  where 
the  statement  HR.manufacturing  <—  P9  is  included  and  all 
other  non-permanent  statements  are  removed.  The  value 
of  P9  is  a  generic  principal  name  and  has  no  effect  on 
the  outcome.  This  leads  to  a  state  where  HQ.ops  contains 
P9,  but  HQ.marketing  is  empty.  This  brief  example  was 
performed  on  a  Pentium  4  2.8  GHz  with  Windows  XP. 


Initial  Policy 

HQ.marketing  <—  HR. managers 
HQ.marketing  <—  HQ. staff 
HQ.marketing  <—  HR. sales 
HQ.marketing  <—  HQ.marketingDelg  n 
HR.employee 
HQ.ops  <—  HR. managers 
HQ.ops  <—  HR.manufacturing 

HQ. marketingDelg  <—  HR. managers. access 

HR. employee  <—  HR. managers 
HR.employee  <—  HR. sales 
HR.employee  <—  HR.manufacturing 
HR.employee  <—  HR.researchDev 
HQ. staff  4—  HR. managers 

HQ.  staff  <—  HQ.specialPanel  Pi 

HR.researchDev 

HR.  manager <—  Alice 
HR.researchDev  «—  Bob 
Growth  &  Shrink  Restricted 
HQ.marketing 

HQ. ops 

HR. employee 
HQ.marketingDelg 
HQ. staff 


Figure  14.  Consider  the  queries:  HR.employee 
□  HQ.marketing,  HR.employee  □  HQ.ops, 
HQ.marketing  □  HQ.ops 


6.  Related  &  Future  Work 

Security  requirements  of  business  systems  express  the 
goals  for  protecting  the  confidentiality,  integrity  and  avail¬ 
ability  of  assets.  There  has  been  substantial  work  on  de¬ 
veloping  models  and  policy  languages  for  addressing  these 
security  concerns  [13,  9].  To  enforce  the  correctness  (e.g. 
completeness  and  lack  of  conflicts)  of  policy  specifications, 
policy  language  formalization  and  analysis  have  been  per¬ 
formed  using  different  techniques  such  as  formal  languages, 
automata  theory,  logic  programming  [9],  and  theorem  prov¬ 
ing  [5].  However,  these  reasoning  approaches  require  more 
expertise  and  efforts,  and  sometimes  have  less  tool  support, 
which  are  barriers  for  practitioners  to  adopt  these  formal 
techniques  in  developing  secure  software  systems. 

To  alleviate  this  problem,  researchers  have  been  work¬ 
ing  towards  developing  automated  tools  to  examine  secu¬ 
rity  properties  using  lightweight  formal  analysis  techniques 
[3,  4,  6,  10,  14],  such  as  model  checking.  Zhang  et.  al. 
[15]  developed  a  model  checking  approach  to  examine  the 
access  rights  of  a  group  of  principals.  The  access  control 
is  modeled  in  the  RW  language,  which  is  a  propositional 
logic-based  policy  language  to  express  reading  and  writing 


access  [6].  However,  role  delegation  expressed  as  Type  II 
or  Type  III  RT  statements  cannot  be  expressed  and  checked 
using  their  approach.  May  et.  al.  [10]  formalized  the  rules 
of  Health  Insurance  Portability  and  Accountability  Act  into 
an  extended  access  control  matrix,  which  can  be  analyzed 
by  model  checker  SPIN.  However  delegation  in  access  con¬ 
trol  matrices  does  not  scale  well.  Fisler  et.  al.  [3]  intro¬ 
duced  Margrave  as  a  tool  to  analyze  the  impact  of  changes 
in  XACML  policy.  Their  focus  is  on  role-based  access  con¬ 
trol  as  opposed  to  TM  and  thus  they  do  not  address  delega¬ 
tion. 

In  the  future,  we  plan  to  optimize  the  preprocessing  us¬ 
ing  RDG  to  reduce  the  state  space  and  reduce  the  number 
of  statements/principals  necessary  to  verify  a  property.  In 
addition,  it  is  desirable  to  find  the  tight  bound  of  extra  prin¬ 
cipals  in  the  MRPS.  Finally  we  intend  to  show  that  this  ap¬ 
proach  is  feasible  on  extended  variants  of  RT,  to  possibly 
include  negated  policy  statements. 

7.  Conclusions 

Security  analysis  of  trust  management  policies  is  an 
important  step  towards  provably  secure  software  systems. 
Whereas  the  trust  management  approach  provides  the  seal- 
ability  and  flexibility  to  handle  real  world  access  control 
requirements,  the  dynamic  and  indirect  nature  of  delegation 
does  not  always  provide  an  intuitive  sense  as  to  what  the 
limitations  on  resources  are  actually  in  place.  This  paper 
proposes  a  fully  automated  approach  to  performing  security 
analysis  in  trust  management.  We  demonstrate  the  feasibil¬ 
ity  of  translating  trust  management  policies  into  the  input 
language  of  a  model  checker  to  analyze  role  containment. 
By  translation,  we  support  reuse  of  existing  policy  language 
and  analysis  tools  to  take  advantage  of  policy  language  ex¬ 
pressiveness  and  analysis  tools’  optimization.  We  also  show 
that  this  approach  can  also  be  used  in  other  security  policy 
analysis  such  as  separation  of  duty,  safety,  and  availability. 
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